4.1.1.  OGC API — Maps

The OGC API — Maps draft specification describes an API that can serve spatially referenced and dynamically rendered electronic maps. The specification describes the discovery and query operations of an API that provides access to electronic maps in a manner independent of the underlying data store. The query operations allow dynamically rendered maps to be retrieved from the underlying data store based upon simple selection criteria, defined by the client.

4.1.2.  OGC API — Styles

OGC API — Styles specifies building blocks for Web APIs that enable map servers and clients as well as visual style editors to manage and fetch styles that consist of symbolizing instructions that can be applied by a rendering engine on features and/or coverages. The API implements the conceptual model for style encodings and style metadata. The model defines three main concepts, namely the style, stylesheet, and style metadata. The concepts are explained below:

• The style is the main resource.

• Each style is available in one or more stylesheets — the representation of a style in an encoding like OGC SLD 1.0 or Mapbox Style. Clients will use the stylesheet of a style that fits best based on the capabilities of available tools and their preferences.

• For each style there is style metadata available, with general descriptive information about the style, structural information (e.g., layers and attributes), and so forth to allow users to discover and select existing styles for their data.

4.1.3.  OGC API — Tiles

OGC API — Tiles specifies a standard for Web APIs that provide tiles of geospatial information. The standard supports different forms of geospatial information, such as tiles of vector features (“vector tiles”), coverages, maps (or imagery) and potentially eventually additional types of tiles of geospatial information.

Vector data represents geospatial objects such as points, lines, and polygons. Tiles of vector feature data (i.e. Vector Tiles) represent partitions of vector data covering a large area (e.g. lines representing rivers in a country).

In this context, a map is essentially an image representing at least one type of geospatial information. Tiles of maps (i.e. Map Tiles) represent subsets of maps covering a large area (e.g. a satellite image).

4.1.4.  OGC STAplus — an extension of the OGC SensorThings API

STAplus is an extension to the OGC SensorThings data model. Inspired by Citizen Science applications, STAplus supports the ‘ownership concept’ whereby observations collected by sensors are owned by (different) users that may express the license for re-use. In addition to the ownership and license abilities, the extension specified by STAplus supports the expression of explicit relations between observations and the creation of group(s) of observations.

4.1.5.  OGC Styled Layer Descriptor

The Styled Layer Descriptor (SLD) encoding standard defines an encoding that supports user-defined symbolization and coloring of geographic feature and coverage data. SLD addresses the need for users and software to be able to control the visual portrayal of the geospatial data. The ability to define styling rules requires a styling language that the client and server can both understand. SLD is often used in combination with the OGC Symbology Encoding Standard (SE).

4.1.6.  OGC Styles and Symbology

The OGC Symbology Conceptual Model: Core Part standard (OGC 18-067r3), also known as OGC SymCore, specifies the conceptual basis to define symbology rules for the portrayal of geographical data. It is modular and extensible (one core model, many extensions), also encoding agnostic (one symbology model, many encodings). It contains a minimal set of abstract classes representing explicit extension points of the model.

OGC Styles and Symbology is a vision for a standard that implements the OGC Symbology Conceptual Model: Core Part standard (OGC 18-067r3). The Web Mapping Code Sprint was a key moment to consolidate the roadmap to achieve this vision. The plan towards such a candidate SymCore 2.0 standard specdoc will consist in the definition of a conceptual and logical model, CSS and JSON encodings and a mapping to SLD/SE (eventually with existing well known vendor options). The requirements described will be supported by illustrated and encoded cartographic use cases.

4.2.1.  Leaflet

Leaflet is a popular Javascript library for displaying maps in web pages, created in 2011 by Volodymir Agafonkin and released under a BSD-2 license. It has a minimalistic architectural design in order to provide a small code footprint. As a result, any advanced or specific functionality is implemented by plugins.

Leaflet.ImageOverlay.OGCAPI is a Leaflet plugin implementing a OGC API — Maps client, and was created during a previous codesprint.

4.2.2.  ldproxy

ldproxy is an implementation of the OGC API family of specifications, inspired by the W3C/OGC Spatial Data on the Web Best Practices. ldproxy is developed by interactive instruments GmbH, written in Java (Source Code), and is typically deployed using docker (DockerHub). In addition to supporting commonly used data formats for geospatial data, an emphasis is placed on an intuitive HTML representation.

The current version supports PostgreSQL/PostGIS databases, GeoPackages and WFS 2.0 instances as backends for feature data. MBTiles is supported for tilesets.

ldproxy implements all conformance classes and recommendations of “OGC API — Features — Part 1: Core” and “OGC API — Features — Part 2: Coordinate Reference Systems By Reference” and is an OGC Reference Implementation for the two standards. ldproxy also supports the OGC API Records draft as well as the draft extensions of OGC API — Features (that is Part 3, CQL2, Part 4 and most of the current proposals discussed by the Features API working group). It supports GeoJSON, JSON-FG, HTML, FlatGeoBuf, CityJSON, glTF 2.0 and GML as feature encodings.

ldproxy also has implementations for additional resource types: Vector and Map Tiles, Styles, Routes, 3D Tilesets.

ldproxy is distributed under the Mozilla Public License 2.0.

4.2.3.  Miramon Map Browser

The Centre for Ecological Research and Forestry Applications (CREAF) at the Autonomous University of Barcelona (UAB) deployed an instance of the MiraMon Map Browser and available in GitHub. The MiraMon Map Browser is a web application for creating visualization and analysis solutions that run in modern web browsers. The browser uses HTML5, JavaScript, and supports OGC Standards such as OGC API — Tiles, WMS, and WMTS. The JavaScript client is able to combine AJAX, binary arrays, the WMS/WMTS protocols, the OGC API Maps and the OGC API Tiles. The MiraMon Map Browser has also been extended to support STAplus, an extension of the OGC SensorThings API standard.

4.2.4.  OSGeo OWSLib

OWSLib is a Python client for OGC Web Services and their related content models. The project is an OSGeo Community project and is released under a BSD 3-Clause License.

OWSLib supports numerous OGC standards, including increasing support for the OGC API suite of standards. The official documentation provides an overview of all supported standards.

4.2.5.  OSGeo pygeoapi

pygeoapi is a Python server implementation of the OGC API suite of standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license. pygeoapi is an official OSGeo Project as well as an OGC Reference Implementation.

pygeoapi supports numerous OGC API Standards. The official documentation provides an overview of all supported standards.

4.2.6.  STAplus Viewer App by Secure Dimensions

The STAplus Viewer App is a proof of concept implementation as Web-Browser application based on JavaScript and Leaflet. The implementation further leverages JS libraries from STAM (SensorThings API Map) developed by Datacove for INSPIRE.

The STAplus Viewer App is based on the Leaflet JavaScript library. It is however possible to base the application on OpenLayers. This alternative implementation is available from the COS4Cloud project. Even though it looks and feels slightly different, both implementations provide the same functionality.

4.2.7.  TEAM Engine

The Test, Evaluation, And Measurement (TEAM) Engine is a testing facility that executes test suites developed using the TestNG framework or the OGC Compliance Test Language (CTL). It is typically used to verify specification compliance and is the official test harness of the OGC Compliance Testing Program (CITE).

4.2.8.  OpenLayers

OpenLayers is a library for developing browser-based mapping applications. It works with vector and raster data from a variety of sources and is able to reproject data for rendering. The library has broad support for OGC protocols and formats, including WMS, WMTS, WFS, WKT, WKB, GML, and KML. In addition, it has support for community and non-OGC standards such as GeoJSON, XYZ tiles, TileJSON, GeoTIFF/COG, and more. OpenLayers is written in JavaScript and is available under the BSD 2-Clause license.

The ol/source/OGCMapTile module provides a source for map tiles from an OGC API – Tiles service. The ol/source/OGCVectorTile module provides a source for vector tiles from an OGC API — Tiles service.

4.2.9.  xyz2ogc

The xyz2ogc program supports the generation of OGC API – Tiles metadata from existing XYZ tilesets. The program is implemented in the Go programming language and the published module can be used in Go-based services that implement the OGC API – Tiles specification.

4.3.1.  MariaDB CubeWerx CubeServ

The CubeWerx server (“cubeserv”) is implemented in C and currently implements the following OGC Standards and draft specifications.

• Multiple conformance classes and recommendations of the OGC API — Tiles — Part 1: Core Standard.

• Multiple conformance classes and recommendations of the OGC API — Maps — Part 1: Core candidate Standard.

• All conformance classes and recommendations of the OGC API — Features — Part 1: Core Standard.

• Multiple conformance classes and recommendations of the OGC API — Records — Part 1: Core candidate Standard.

• Multiple conformance classes and recommendations of the OGC API — Coverages — Part 1: Core candidate Standard.

• Multiple conformance classes and recommendations of the OGC API — Processes — Part 1: Core Standard.

• Multiple versions of the Web Map Service (WMS), Web Processing Service (WPS), Web Map Tile Service (WMTS) and Web Feature Service (WFS) Standards.

• A number of other “un-adopted” OGC Web Service draft specifications including the Testbed-12 Web Integration Service, OWS-7 Engineering Report — GeoSynchronization Service, and the Web Object Service prototype.

The cubeserv executable supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats (e.g., GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems.

4.3.2.  Ordnance Survey Implementation of OGC API — Styles

Ordnance Survey (OS) works with a wide array of customers and partners across many industries in the United Kingdom and beyond. A key part of the current OS Roadmap is the suite of products to deliver the OS National Geographic Database (OS NGD). At the end of September 2022, OS launched the OS NGD API – Features product which implements Parts 1, 2, and 3 of OGC API — Features to provide access to data along with filtering capabilities to enable customers to retrieve just the data they need. During the code sprint, developers from OS focuses on implementation of the OGC API — Styles candidate standard. The work at the code sprint complemented other OS activities that are implementing OGC API — Tiles.

4.3.3.  GNOSIS Map Server

The GNOSIS Map Server is written in the eC programming language and supports multiple OGC API specifications. GNOSIS Map Server supports multiple encodings including GNOSIS Map Tiles (which can contain either vector data, gridded coverages, imagery, point clouds or 3D meshes), Mapbox Vector Tiles, GeoJSON, GeoECON, GML and MapML. An experimental server is available online at https://maps.ecere.com/ogcapi and has been used in multiple OGC Innovation Program initiatives.

4.3.4.  Hexagon Luciad RIA

LuciadRIA is a product that enables applications running in a web browser to offer 2D, 3D, or 4D visualization of satellite and other imagery, vector-based data and dynamic content, such as tracks. LuciadRIA can connect to implementations of OGC API Standards, as well as implementations of OGC Web Service standards.

5.3.1.  OGC API — Tiles implementation

Leaflet has built-in support for map tiles (or “TileLayer”s), but its internal implementation has significant constrains: All TileLayers must share the same coordinate system, must be aligned to the same origin of coordinates, and all tiles in any given TileLayer must have the same pixel size.

The flexibility of OGC API — Tiles in regards of tile size and origin of coordinates both prove a handicap for a Leaflet client implementation.

The reached consensus is to ignore TileMatrixSets which do not have a constant tile size, or that do not have a common origin of coordinates for the (0,0) tiles.

5.3.2.  OGC API — Maps implementation

An instance of leaflet was configured to access an OGC API — Maps implementation from a MariaDB CubeSERV instance. The CubeSERV instance had been configured to offer an OGC API — Maps façade in front of a WMS that offered layers of the EuroRegionalMap of EuroGeographics. A screenshot of the leaflet instance is shown in Figure 6.

Figure 6 — Screenshot of leaflet accessing implementations of OGC API - Maps and OGC API - Tiles.

5.4.1.  OGC API — Tiles

The participants from interactive instruments GmbH updated their OS Zoomstack demonstration server to support the released version of OGC API — Tiles — Part 1: Core standard. Specifically, ldproxy now offers a link that can be followed to get to a tile matrix set definition. The link is provided through a uri property as shown in the following listing.

{
  "links" : [ {
    "rel" : "self",
    "type" : "application/json",
    "title" : "This document",
    "href" : "https://demo.ldproxy.net/zoomstack/tileMatrixSets?f=json"
  }, {
    "rel" : "alternate",
    "type" : "text/html",
    "title" : "This document as HTML",
    "href" : "https://demo.ldproxy.net/zoomstack/tileMatrixSets?f=html"
  } ],
  "tileMatrixSets" : [ {
    "title" : "Google Maps Compatible for the World",
    "links" : [ {
      "rel" : "self",
      "title" : "Tile matrix set 'WebMercatorQuad'",
      "href" : "https://demo.ldproxy.net/zoomstack/tileMatrixSets/WebMercatorQuad"
    } ],
    "id" : "WebMercatorQuad",
    "uri" : "http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad"
  } ]
}

Screenshots of the ldproxy landing page (a) and its WebMercatorQuad tile matrix set definition (b) are shown in Figure 7.

Figure 7 — Screenshot of the ldproxy landing page (a) and its WebMercatorQuad tile matrix set definition (b)

5.4.2.  OGC API — Styles

The ldproxy demonstration implementation of OGC API — Styles was updated with additional styles during the code sprint. The demo server provided a reference for other participants to validate their implementations by. A screenshot a listing of styles offered by the ldproxy demo is shown in Figure 8 (a) and metadata about a single style is demonstrated in Figure 8 (b).

Figure 8 — Screenshot of the listing of styles offered by the ldproxy demo (a) and style metadata (b)

The work on OGC API — Styles during the code sprint led to a pull request being created to update the candidate standard. The pull request clarifies how to apply changes to a style with multiple occurrences in an API.

5.5.1.  Contribution

The sprint participants from Hexagon, Robin Houtmeyers and Tom Crauwels, divided their efforts between the server side and the client side. On the server side they integrated OGC API — Tiles as a possible service option in LuciadFusion Studio. On the client side they created a prototype connector for the OGC API —  Maps candidate Standard and the OGC API — Tiles Standard in LuciadRIA and integrated the connector into the LuciadRIA Data Formats sample. More developer focused information such as documentation, API reference, samples, videos, etc can be found on https://dev.luciad.com/ .

5.5.2.  Server side with LuciadFusion

LuciadFusion provides an all-in-one server solution for geospatial data management. At it’s core is an API that can be used to develop custom server solutions. It ships with LuciadFusion Studio, an out-of-the-box web frontend application developed on top of that API, that lets an end-user manage data intelligently, store and process a multitude of data formats and feed data to multiple applications. A demonstration video can be found here.

The sprint participants from Hexagon started from an earlier prototype that could offer data through an OGC API — Tiles interface. The goal of the earlier prototype was a proof of concept, a document that explains how to add support for OGC API — Tiles and a rough estimate of the workload. Since OGC API — Tiles is defined using the OpenAPI specification, the OpenAPI specification and the tool OpenAPI Generator could be used to generate domain models and REST controllers (for example: Spring controllers). 

During this sprint, that earlier prototype was integrated into LuciadFusion Studio as a proof of concept. This means that after adding or crawling data, it could be published as a service that implements OGC API — Tiles, next to existing services such as WMS, WMTS, etc. This functionality was demonstrated in a short video with sample data downloaded from Ordnance Survey’s OS Data Hub:

https://osdatahub.os.uk/downloads/open/250kScaleColourRaster

Figure 10

Note: this is still work in progress; there is no out-of-the-box LuciadFusion prototype with OGC API support available yet. 

5.5.3.  Client side with LuciadRIA

5.5.3.2.  Capability parsing

Many of the new OGC API Standards offer a central overview of all data sets available on a server in JSON (or xml, html) at a “collections” URL. This central overview offers links to specific collections (with a unique ID) which in turn can offer links to maps, tiles, styles, etc. An overview from the GNOSIS Map Server:

/ogcapi/collections/{collectionID}(collection description)
/ogcapi/collections/{collectionID}/tiles(vector tiles)
/ogcapi/collections/{collectionID}/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}(individual vector tile)
/ogcapi/collections/{collectionID}/map/tiles(map tiles)
/ogcapi/collections/{collectionID}/map/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}(individual map tile)
/ogcapi/collections/{collectionID}/coverage/tiles(map tiles)
/ogcapi/collections/{collectionID}/coverage/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}(individual coverage tile)
/ogcapi/collections/{collectionID}/items(vector features)
/ogcapi/collections/{collectionID}/coverage(coverage)
/ogcapi/collections/{collectionID}/map(map)
/ogcapi/collections/{collectionID}/styles/{styleId}/map(styled layer map)
/ogcapi/map(dataset map)
/ogcapi/styles/{styleId}/map(styled dataset map)
/ogcapi/tileMatrixSets/{tileMatrixSetId}(individual tiling scheme)

In the Data Formats sample, the team created a ConnectToOGCAPIMapsWizard and added it to the ConnectToModal. This wizard creates an OGCAPIMapsCapabilities object after connecting to a valid URL, which contains a collection of OGCAPIMapsCapabilitiesLayer objects, one for each collection available. Finally a OGCAPIMapsLoader is used to create a model and layer that LuciadRIA can use to load and visualize the data.

Figure 11

5.5.3.3.  Retrieving tiles

Retrieving data can be done in 2 distinct ways: /map or /tiles. The first way, /map, is very similar to how WMS works, a user can request data for a certain bounding box. The newer way, available from /tiles, is similar to how many popular map servers, such as OpenStreetMap (OSM), work. The tiles are cut using a certain tile matrix set (https://www.ogc.org/standards/tms) and can then be requested using a format such as:

collections/{collectionID}/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}

So for example:

collections/bluemarble/tiles/WebMercatorQuad/0/0/0.png

Multiple tile matrix sets can be offered and their specifications can be requested (in JSON or HTML). The specification offers the width and height of tiles, the number of columns and rows, the scale and a way to calculate the bounding box, so everything a client needs to calculate each tile. In the LuciadRIA example implementation, the team focused on the classic quad tree structure such as WebMercatorQuad.

The team extended https://dev.luciad.com/portal/productDocumentation/LuciadRIA/docs/reference/LuciadRIA/classes/ria_model_tileset_urltilesetmodel_d.urltilesetmodel.html[UrlTileSetModel] to implement such a connection. It would map easily on the /tiles offering, since it works exactly like that. To connect to the /maps offering, the team used the function getTileBounds to calculate the bounds of a certain tile and then replace the URL so that it matches the OGC API — Maps Standard and send a bounding box (with crs) to the server.

Figure 12

5.5.3.5.  Reprojecting

One of the core strengths of the Luciad portfolio is that it can be used to connect to and visualize data in any format or projection. LuciadRIA can even utilize the power of the GPU through WebGL to on the fly project data, such as imagery and vector data, to any known projection and visualize it as such. To demonstrate this we added another menu option in the sample to switch to different projections.

Figure 13

Figure 14

Figure 15

Next to some predefined options such as 3D, CRS84, WebMercator and a projection requested by another participant (British National Grid projection (EPSG:27700)), we also added the option to load any projection known to LuciadRIA. To minimize the size of a LuciadRIA application, not all projections are available in it out of the box. However, other projections can be added as WKT (Well Known Text)) by its identifier, which in most cases will be an EPSG code. If LuciadRIA does not know this code, it will automatically try to request it from https://epsg.io/ which is an Open Source project that holds a collection of all known projections and can format them into WKT. After getting the WKT, the application will be restarted in the new projection and any subsequently loaded data will be reprojected into that projection.

5.5.4.  Resources

The LuciadRIA demonstration sample (= extended Data Formats sample) is available online:

https://demo.luciad.com/OGCAPIClient/?webgl&reference=epsg:4978

Using the Connect to button at the bottom, you can add connections to OGC API Maps services.

The video created showcasing the LuciadFusion integration can be found here:

https://hexmet-my.sharepoint.com/:v:/g/personal/robin_houtmeyers_hexagon_com/EXchVu0jsyFBiAMVf17xpmcBqjTV-WQHnX2uc17ckBan5w

Servers from other participants used during the sprint:

GNOSIS Map Server: https://maps.gnosis.earth/ogcapi/
CubeServ: https://test.cubewerx.com/cubewerx/cubeserv/demo/ogcapi/EuroRegionalMap

5.6.1.  OGC API – Maps and Map Tiles implementation

To begin with, an overhaul of the code has been made to update the implementation to the approved version of OGC API Tiles and the current draft version OGC API Maps. A working instance of the MiraMon web client implementation was prepared showing collections from multiple providers.

Figure 19 — Screenshot of the Miramon Map Browser with a combination of several collections (or layers) in the same client using different OGC protocols and APIs, like WMS, WMTS, OGC API — Maps, OGC API — Tiles, and SensorThings API

After that, the work focused on having a full implementation of the OGC API — Maps in our web client to allow end users to add collections from external server. The map client is able to establish the connection with a server from the landing page, inspect and follow the links and make the necessary requests to obtain a list of available map collections and their main characteristics.

The interface allows to end users to indicate the landing page of the service that should be explored. Once explored, it displays a list of map collection available and allows to users select the collection or collections to add them as layer in the legend and in the map screen. The following images show the .

Figure 20 — Screenshot of the first step of the process for adding collections to the client from a OGC API — Maps compatible landing page prepared by Cubewerx

Figure 21 — Screenshot of the collection list presented to the user to be added to the client. The Cubewerx offers only one collection: the European topographic map from the sponsor Eurogeographics.

Figure 22 — Screenshot of the Eurogeographics map served by the Cubewerx API.

Finally, the working shifted to connecting to map collections from OCG API — Tiles so that the end user can be added tiled maps to the client. The work consist on obtaining the tiled description and the list of tiled maps available in a service from the landing page. The work was more extensive that we anticipated and in the process of an in-depth review of the standard documents some difficulties have been found to properly understand some aspects. A suggestion for incorporating more coding examples in some of the requirements classes was made.

5.6.2.  OGC Sensor Things API implementation

When working with a large amount of citizen data accessible through a STA service. In particular, trying to request the necessary data to present a map with a the large volume of features of interest can very slow and inefficient. To solve two approaches to tessellate the data has been tested and others proposed.

5.6.2.2.  A client side implementation

A client-based tessellation solution was implemented in the sprint that addressed the situation of a server that offers a significant number of vector objects, whether those objects represent features, sensors, or their observations. This approach requires to implement two aspects directly in the client side: a tile matrix set and a “pre-fetch” STA request for the number of features in a tile.

By defining a tile matrix set in several zoom in the client side, parallel tiled requests based on this division can be done to the server by specifying the bounding box of each tile without changing anything in the standard or the server implementations. In addition, only the tiles with a number of objects below a threshold will be completely requested.

Miramon was configured to issue a request for each STA tile twice, the first request is for getting the count (i.e. number of features of interest in a tile), and then second request is for getting the actual features of interest. The number of features of interest is requested to the STA server in a prefetch request. Only if the count of the features in the “tile” requested is greater than the threshold, only the number of features of interest is represented in the center of the tile with the presentation of the number of objects in each tile. Otherwise, the full description of the features of interest in the tile is requested and each feature of interested is represented in the screen. This approach is proposed by the STAM library and it has been implemented from scratch in the MiraMon Map Browser using the same principles.

Figure 23 — Screenshot of the MiraMon Map Browser requesting counts of features of interest to a modified FROST implementation of STA hosted by Secure Dimensions. The observations in the STA are point type biodiversity occurrences.

Figure 24 — Screenshot of the MiraMon Map Browser requesting some tiles with the count of features of interest represented as big circles and others with the features of interest represented as small red dots. In addition, the information related with a particular observation is shown, including a picture.

Figure 25 — Screenshot of the MiraMon Map Browser showing the URLs requested for each tile where the each bounding box can be seen expressed in WKT as a polygon.

5.6.2.3.  A Server side implementation

Secure Dimensions has contributed to this sprint a server side implementation of tiles of observations. In this case a OGC API — Tiles is used as a facade for STA. The server implementing the OGC API — Tiles, renders the STA observation in PNG on-the-flight that is immediately delivered to the client. The MiraMon Map Browser is used as a client for this approach in other to visually verify that both server and client side times generate the same view. Further work is need to evaluate which of the two approaches could be more efficient in concrete use cases.

Figure 26 — Screenshot of the MiraMon Map Browser comparing the response of the the Secure Dimensions OGC API - tiles facade (bottom, represented as black dots) with a STA with the client side tile approach (top, represented as red dots) as described in the previous subsection. Spatial concordance between the position of the features of interest is checked.

5.10.1.  OGC API — Maps implementation

The pygeoapi project implemented support for the OGC API — Maps — Part 1: Core draft specification. Support for the Requirements Class “Map Core” was implemented, reviewed and approved by the pygeoapi development team. As a result, pygeoapi implementations are now able to easily publish geospatial data as dynamic maps thanks to the building block approach of OGC API Standards.

pygeoapi’s plugin architecture facilitated the implementation of two plugin backends for maps:

• MapScript: using the MapServer[https://mapserver.org] web mapping engine as the map renderer, using data and styling definitions (Styled Layer Descriptor [SLD], MapServer CLASS configuraiton files).

• WMSFacade: a bridge/mediator to expose existing OGC WMS 1.3 services via OGC API — Maps

The official pygeoapi documentation provides more information on how to enable the new functionality. A screenshot of the associated OpenAPI/Swagger interface from the implementation is shown in the figure below.

Figure 31 — Screenshot of pygeoapi OGC API — Maps MapScript plugin

Figure 32 — Screenshot of pygeoapi OGC API — Maps WMSFacade plugin

Figure 33 — Screenshot of pygeoapi OGC API — Maps via OpenAPI/Swagger

Figure 34 — Screenshot of pygeoapi OGC API — Maps WMSFacade using the Open Maps for Europe WMS from Eurogeographics

5.10.2.  OGC API — Tiles updates

5.10.2.1.  Tile Metadata

Support for the Tile Set Metadata schema has been added to TileJSON MapBox. It is also possible to support any format by adding a JSON metadata file directly into the filesystem. As well, the absence of metadata does not represent an issue, facilitating support for different tiles providers.

Figure 35

5.10.2.2.  Vector tiles URL templates

pygeoapi added support for rendering OGC API — (vector) tiles from a third-party service, using a generic URL template. One use case for this functionality would be to stream elasticsearch vector tiles, which are provided in elasticsearch >=8, as OGC API — Tiles.

Figure 36 — Screenshot of pygeoapi OGC API — Tiles using the Elasticsearch vector tiles

We could also use this functionality to render pg_tileserv vector tiles, or any other service which uses format {z}/{y}/{x} or {z}/{x}/{y}

Figure 37 — Screenshot of pygeoapi OGC API — Tiles connecting to a pg_tileserv vector tiles service

5.10.3.  OGC API — Coverages browser rendering

pygeoapi gained HTML representation of a coverages, as a lightweight HTML viewer.

This viewer is a Leaflet[https://leafletjs.com/] implementation, which uses the Leaflet.ImageOverlay.Arrugator[https://gitlab.com/IvanSanchez/Leaflet.ImageOverlay.Arrugator/] plugin, and the proj4js[https://github.com/proj4js/proj4js/] library to provide client-side reprojection. Whenever a web browser visits a /coverage path on pygeoapi, the web browser sends an Accept: text/html header which triggers pygeoapi to respond with the lightweight coverage viewer.

Figure 38 — Screenshot of pygeoapi lightweight coverage viewer

The emphasis is not in the viewer, but rather in the fact that the viewer is the HTML representation of the coverage resource. Whenever a API client requests the coverage resource, it will be given a HTML map viewer, or the JSON-LD representation of the coverage, or the raw coverage data (as PNG, GeoTIFF, NetCDF, etc), in accordance to the established HTTP content negotiation rules (“Accept” HTTP headers, or “f” URL parameter).

This is aligned with pygeoapi’s implementation of OGC API — Features, where requesting features as HTML returns a map viewer loaded with those features.

5.10.4.  Mentor session

A pygeoapi mentor session was provided in support of delivering Vector Tiles using pygeoapi. The session focused on:

• installation

• overview of various endpoints and Creating standard source

• creating vector tiles

• serving vector tiles

• reading vector tiles from different clients

5.10.5.  Developer outreach

Members of the pygeoapi development team discussed project participation and contributions with various developers at the sprint.

5.12.1.  OGC API – Tiles updates

A previous OpenLayers release had “experimental” support for rendering tiles from OGC API – Tiles services. This was added prior to the OGC API – Tiles standard being finalized.

During the sprint, the implementation was tested against services conforming to the Tileset conformance class. Changes were proposed to graduate the the source classes for rendering vector and map tiles from experimental to stable. These changes were approved, and the classes will be part of the OpenLayers API in the next release.

Figure 41 — Map tiles from an OGC API – Tiles service in OpenLayers

Figure 42 — Vector tiles from an OGC API – Tiles service in OpenLayers

5.13.1.  Findings

The OGC API – Tiles specification makes it easy for existing XYZ tilesets to conform with the Core requirements. This is possible as long as the service provides some way for the tile URL template and the meaning of the variables in that template to be obtained.

Since many existing XYZ tilesets do not have a formalized way for clients to obtain the tile URL template or understand the meaning of the variables, it makes sense for tile providers to “upgrade” their services by conforming with the Tileset requirements.

In practice, conforming with the Tileset requirements means hosting two metadata documents for a single XYZ tileset: one providing the tileset metadata and one describing the tiling scheme. This can be reduced to a single document for the tileset metadata linking to an existing document hosted elsewhere that describes the tiling scheme.

It would be more convenient if OGC specifications were developed in a way that URIs for things like CRS or TileMatrixSet resolved to definitions of those resources. For example, it would be convenient if the WebMercatorQuad URI resolved to the definition for this tile matrix set. This would allow the tiling scheme for a tileset to be specified with the tile matrix set URI alone, and clients could reliably fetch the definition from this. Unfortunately, it is not enough for the OGC URIs to redirect to a different resource providing this content. A browser-based client served via the HTTPS protocol will not fetch the OGC URI unless it is served via HTTPS (to avoid mixed active content violations) and it is served with Cross-Origin Resource Sharing (CORS) headers.

Suggestion: If in the future OGC URI 1) used the HTTPS scheme, 2) resolved to useful resources, and 3) were served with CORS headers, it would make browser-based client implementations easier.

For services providing more than a single tileset, it makes sense to conform to the Tileset List requirements. Having conformed with the Tileset requirements, it is mostly straightforward to conform to the Tileset List requirements by providing a document that lists the metadata (or a subset of the metadata) for each tileset. In the case of a static server, requirement 9 adds a small additional burden on implementators. The specification requires that the URL for the list of tilesets ends with /tiles. In many cases, static servers determine the conent type for a response based on a document extension. For example, a common pattern is to have an index.html document that the server will provide in response to a request that matches a directory location (e.g. https://example.com/path/to/directory/). The same can be done for an index.json document with a list of tilesets as long as the service can be configured to treat index.json files as the “default” document. The additional potential complication is that the service may need to be configured to redirect a slash-less URL (e.g. https://example.com/path/to/tiles) to a URL ending in a slash (e.g. https://example.com/path/to/tiles/) so that the default document will be served.

Suggestion: If there is not a real benefit to requiring that the tileset list URL ends with /tiles, perhaps a future version of the specification could relax or remove this requirement.

In addition to the Tilset, Tileset List, and associated TMS conformance classes, the xyz2ogc program implements a few of the conformance classes from OGC API – Common, namely Core, JSON, and OpenAPI 3.0. However, xyz2ogc chose not to implement the additional requirements from the OGC API – Tiles OpenAPI 3.0 conformance class. In particular, the requirements related to homogenous collections of tilesets (e.g. not including vector tiles in a list that includes map tiles) didn’t match the design of the project (a single listing of tilesets that may include both vector and map types). A client capable of rendering both vector and map tiles can make this distinction invisible to users, and the idea with the xyz2ogc program is to provide users with a list of tilesets to choose from – dividing those into multiple lists based on tile content type seems arbitrary and a bit awkward.

Suggestion: In the future, it could be useful if the specification allowed for linking to tilesets lists of mixed types.